📚 Week 5 · Unit III · Lecture 13
Version Control
Systems & SCM History

Understanding why version control is the single most important tool in a developer's toolkit — and tracing its evolution from manual file copies to modern distributed systems.

Dr. Mohsin Furkh DarSchool of Computer Sciences
DateMon, 06 Jul 2026 · 9:00 – 10:00 AM
ProgrammeBTech CSE – Summer Semester
Today's Agenda
1
Recap — DevOps Toolkit & CI/CD
2
What Is Version Control? — The Problem It Solves
3
Types of VCS — Local, Centralized, Distributed
4
History of SCM — From SCCS to Git
5
Key Concepts — Repositories, Commits, Branches
6
Why Git Won & Key Takeaways
Recap
Where We Left Off
✅
Lecture 12: We mapped the complete DevOps toolchain (Plan → Code → Build → Test → Release → Deploy → Operate → Monitor), explored popular tools in each category, and dove deep into CI/CD — Continuous Integration, Continuous Delivery vs. Deployment, deployment strategies, and the CI/CD maturity model.
🎯
Today: We zoom into the "Code" phase of the toolchain — specifically Version Control Systems (VCS). VCS is the foundation that makes CI/CD possible. Without it, there's no automated pipeline, no collaboration, and no audit trail. We'll also trace the history of SCM from the 1970s to today.
DevOps Toolchain Position
  • Plan ✔️ → Code 📍 → Build → Test → Release
  • VCS is the "Code" tool — but it touches every other phase
  • CI/CD triggers on VCS events (push, PR, merge)
  • IaC, pipeline configs — all stored in VCS
Why VCS Is Foundational
  • Without VCS → no CI (no automated builds on commit)
  • Without VCS → no code review (no pull requests)
  • Without VCS → no audit trail (who changed what, when)
  • Without VCS → no rollback (can't undo a bad change)
The Problem
Life Without Version Control

Before VCS, developers used manual methods to track changes. This led to predictable — and painful — problems.

😱
The "final_v2_REAL_final" problem: Without VCS, developers resort to file copies with names like project_v1.zip, project_v2_fixed.zip, project_FINAL_really_final.zip. Nobody knows which version is actually current. Sound familiar?
🔀
Merge Conflicts
Two developers edit the same file. They email their versions back and forth. Someone manually merges changes by comparing line-by-line. Mistakes are guaranteed.
💾
Lost Work
Someone accidentally overwrites the latest file with an older version. Days of work vanish. No way to recover — there's no history, just file copies.
🕵️
No Audit Trail
A bug appears in production. Who introduced it? When? Why? With manual copies, there's no way to trace when a specific change was made or by whom.
👥
Collaboration Chaos
Teams of 5+ developers can't work on the same codebase simultaneously. They resort to "locking" files or taking turns — killing productivity.
💡 VCS Solves All of These

Version Control provides: complete history of every change, parallel collaboration without overwriting, instant rollback to any previous state, and a full audit trail of who changed what, when, and why.

Definition
What Is a Version Control System?

A Version Control System is a tool that records changes to files over time, so you can recall specific versions later. It lets multiple people collaborate on a project simultaneously without overwriting each other's work.

— Pro Git (Scott Chacon & Ben Straub)
📸
Snapshots
Every time you "commit," VCS takes a snapshot of all tracked files at that moment. You can return to any snapshot at any time — like an infinite undo.
🌿
Branching
Create isolated workspaces (branches) to develop features without affecting the main codebase. Merge back when ready. Cheap and fast in modern VCS.
🤝
Collaboration
Multiple developers work on the same project simultaneously. VCS tracks who made which changes and intelligently merges them — or flags conflicts for manual resolution.
🔍
Traceability
Every change has a timestamp, author, and message explaining why. You can trace any line of code back to the exact commit that introduced it (git blame).
VCS Types
Three Generations of Version Control

VCS has evolved through three distinct generations — each solving the limitations of the previous one.

Local VCS1970s–80s
Centralized VCS1990s–2000s
Distributed VCS2005–present
💻
Local VCS
Tracks changes on a single machine. A local database records file diffs. Example: RCS (Revision Control System). Limitation: No collaboration — only one developer on one computer.
🏢
Centralized VCS (CVCS)
A single server holds the full history. Developers "check out" files, edit, and "check in." Examples: CVS, SVN, Perforce. Limitation: Server = single point of failure.
🌐
Distributed VCS (DVCS)
Every developer has a complete copy of the repository, including full history. Work offline, commit locally, push when ready. Examples: Git, Mercurial. No single point of failure.
🏆
The industry has settled on DVCS. Over 95% of professional developers use Git (a DVCS). Centralized systems like SVN still exist in some enterprises, but new projects almost universally choose Git. We'll explore DVCS in depth in Unit IV.
Generation 1
Local Version Control Systems
How It Works
  • A local database on your machine stores file "patches" (diffs)
  • Each patch records the difference between one version and the next
  • You can recreate any past version by applying patches in sequence
  • Example: RCS (1982) — stored reverse diffs in a hidden file
Limitations
  • Single user only — no way for two people to collaborate
  • If the local disk dies, all history is lost
  • No concept of remote access or sharing
  • No branching or merging (or very primitive versions)
# RCS example — checking in and out a file
$ ci main.c # Check in (save a version)
$ co -l main.c # Check out with lock (for editing)
# Edit the file...
$ ci main.c # Check in the updated version
$ rlog main.c # View version history
📝
Historical note: Before even local VCS, programmers used the simplest "version control" imaginable: copying the entire project directory and renaming it with a date or version number. (project_2024_01_15/). This is still done today by students and beginners — and it's still error-prone.
Generation 2
Centralized Version Control (CVCS)

To enable team collaboration, CVCS introduced a central server that holds the master repository. All developers connect to this server to check out files, commit changes, and view history.

✅ Advantages over Local VCS
  • Multiple developers can collaborate on the same project
  • Administrators can control who has access to what
  • Single "source of truth" — everyone works from the same base
  • Easier to manage than local VCS for teams
❌ Limitations
  • Single point of failure — server goes down, nobody can commit
  • Network dependency — can't work offline; every operation needs the server
  • Slow branching — branches are expensive copies in SVN
  • Data loss risk — if server disk fails and no backup → entire history lost
CVS
Concurrent
Versions System
1990
SVN
Subversion
(Apache)
2000
P4
Perforce
Helix Core
1995
TFS
Team Foundation
Server (MS)
2005
📌
SVN dominated the 2000s. Apache Subversion fixed many of CVS's problems (atomic commits, directory versioning, better branching). It was the standard for a decade — until Git arrived and changed everything.
Generation 3
Distributed Version Control (DVCS)
🌐
In DVCS, every developer's working copy is a full repository — complete with the entire history of all changes. There's no "central server" requirement (though teams typically designate one for convenience, like GitHub). You clone, not check out.
✈️
Work Offline
Commit, branch, merge, view history — all without network access. Sync with the team when you're back online. Perfect for travel, poor connectivity, or just working on a plane.
💨
Lightning-Fast Operations
Since everything is local, operations like log, diff, and branch are instantaneous — no server round-trip. Git's branching is measured in microseconds, not seconds.
🛡️
No Single Point of Failure
Every clone is a full backup. If the "central" server dies, any developer's copy can become the new server. Data loss is nearly impossible.
🌿
Cheap Branching & Merging
Creating a branch in Git is a pointer update (40 bytes). Merging is intelligent and fast. This enables workflows like feature branches, GitFlow, and trunk-based development.
Git
Linus Torvalds
2005
Hg
Mercurial
2005
Bzr
Bazaar
(Canonical) 2005
95%+
Developers
use Git today
SCM History
The Evolution of Software Configuration Management

SCM (Software Configuration Management) is the broader discipline that includes version control, build management, and release management. Here's how VCS evolved within it.

1972
Bell Labs
SCCS — Source Code Control System
The first VCS ever created, by Marc Rochkind at Bell Labs. Stored deltas (differences) for individual files. UNIX-only, single-user. Revolutionary for its time.
1982
Purdue
RCS — Revision Control System
Walter Tichy's improvement on SCCS. Stored reverse deltas (latest version stored in full, older versions as diffs). Faster access to the current version. Still single-user.
1990
Open Source
CVS — Concurrent Versions System
Built on top of RCS, but added client-server networking and concurrent access. Multiple developers could work simultaneously. Dominated the open-source world for a decade.
2000
Apache
SVN — Subversion
Created as "CVS done right." Added atomic commits, directory versioning, binary file support, and better branching. The dominant VCS of the 2000s.
2005
Linus
Git — The Revolution
Created by Linus Torvalds for Linux kernel development after BitKeeper's free license was revoked. Distributed, blazing fast, data-integrity focused (SHA-1 hashing). Changed everything.
The Git Story
How Git Was Born

I'm an egotistical bastard, and I name all my projects after myself. First Linux, now Git.

— Linus Torvalds, 2005
1
2002 — Linux Kernel Uses BitKeeper
The Linux kernel team adopted BitKeeper, a proprietary DVCS that offered free licenses for open-source projects. It worked well for the massive, distributed kernel team.
2
2005 — BitKeeper Revokes Free License
A dispute between the BitKeeper company and a Linux developer led to the revocation of the free license. The kernel team suddenly had no VCS.
3
April 2005 — Linus Creates Git
In just 10 days, Linus Torvalds wrote the first version of Git. Design goals: speed, simplicity, strong support for non-linear development (branching), fully distributed, and able to handle large projects like the Linux kernel.
4
2008 — GitHub Launches
GitHub made Git accessible to everyone with a beautiful web UI, pull requests, and social coding features. Git's adoption exploded — from kernel hackers to every developer on the planet.
5
2018–Today — Git Is Universal
Microsoft acquires GitHub ($7.5B). Over 100 million developers on GitHub alone. Git is the default VCS for virtually all new projects worldwide.
Comparison
VCS Evolution — Feature Comparison
Feature SCCS / RCS CVS / SVN Git / Mercurial
Generation 1st (Local) 2nd (Centralized) 3rd (Distributed)
Architecture Local database Client-server Peer-to-peer (full clone)
Network Required? No (local only) Yes, for all operations No (except push/pull)
Branching None / primitive Expensive (directory copies) Instant (pointer update)
Collaboration Single user Multi-user (lock or merge) Multi-user (merge-first)
Speed Fast (local) Slow (network latency) Very fast (local operations)
Data Safety Low (one disk) Medium (one server) High (every clone is a backup)
Modern Usage Legacy / academic Some enterprises (SVN) Universal standard (Git)
📈
Stack Overflow Developer Survey 2024: 93.9% of developers use Git. The next closest VCS is SVN at ~4%. This is the most one-sided tool adoption in all of software engineering.
Core Concepts
Key VCS Concepts You Must Know

Regardless of which VCS you use, these fundamental concepts are universal.

📁
Repository (Repo)
The database that stores all versions of your files and their history. In Git, this is the hidden .git/ folder inside your project directory.
📸
Commit
A snapshot of your files at a specific point in time. Each commit has a unique ID (SHA hash in Git), author, timestamp, and message describing the change.
🌿
Branch
An independent line of development. Create a branch to work on a feature without affecting main. Merge it back when the feature is complete.
🔀
Merge
Combining changes from one branch into another. VCS automatically merges non-conflicting changes; conflicts require manual resolution.
🏷️
Tag
A named label attached to a specific commit — typically used for releases. E.g., v1.0.0, v2.3.1. Tags don't move; they're permanent markers.
📋
Diff
The difference between two versions of a file (or two commits). Shows exactly which lines were added, removed, or modified — the basis of code review.
SCM Discipline
SCM — More Than Just Version Control

Software Configuration Management (SCM) is the broader discipline that encompasses version control plus several other practices.

SCM Includes
  • Version Control — tracking source code changes (Git, SVN)
  • Build Management — compiling and packaging (Maven, npm, Docker)
  • Release Management — versioning, tagging, and distributing releases
  • Change Management — controlling and approving changes (PRs, code review)
  • Environment Management — maintaining consistent dev/staging/prod environments
SCM in DevOps Context
  • VCS is the foundation of SCM — everything else builds on it
  • CI/CD automates build + release management
  • IaC brings environment management under version control
  • Pull requests formalize change management
  • DevOps essentially automates SCM end-to-end
🔗 SCM ↔ DevOps Connection

SCM predates DevOps by decades, but DevOps modernized it. Traditional SCM was manual and process-heavy; DevOps SCM is automated, code-driven, and integrated into CI/CD pipelines. Everything as Code (app code, infra code, pipeline code, config) — all under version control — is the ultimate expression of SCM.

Git's Dominance
Why Git Won the VCS War
⚡
Speed
Git was designed for the Linux kernel — 15+ million lines of code, thousands of contributors. Operations that took minutes in SVN take milliseconds in Git.
🌿
Branching Model
Git's lightweight branches (just a 40-byte pointer) revolutionized workflows. Feature branches, GitFlow, trunk-based — all made practical by cheap branching.
🔒
Data Integrity
Every object in Git is checksummed with SHA-1. It's impossible to change any file or commit without Git detecting it. Cryptographic guarantee of history integrity.
🐙
GitHub Effect
GitHub (2008) made Git social — pull requests, forks, stars, and a beautiful UI turned Git from a kernel hacker tool into the universal platform for all developers.
🌍
Open Source
Git is free and open source (GPL v2). No vendor lock-in. Massive community. Backed by the Linux Foundation. Every major platform supports it natively.
🔌
Ecosystem
GitHub Actions, GitLab CI, Bitbucket Pipelines — the entire CI/CD ecosystem is built around Git. Choosing another VCS means losing access to this ecosystem.
Summary
Key Takeaways — Lecture 13

Today we explored what version control is, why it matters, and how it evolved from single-file local systems to Git's distributed revolution.

01
Why VCS ExistsVCS solves the problems of lost work, merge conflicts, no audit trail, and collaboration chaos. It's the foundation of modern software development and CI/CD.
02
Three GenerationsLocal (RCS) → Centralized (CVS, SVN) → Distributed (Git, Mercurial). Each generation solved the limitations of the previous one.
03
SCM HistorySCCS (1972) → RCS (1982) → CVS (1990) → SVN (2000) → Git (2005). Git was born from necessity when BitKeeper revoked the Linux kernel's free license.
04
Core ConceptsRepository, Commit, Branch, Merge, Tag, Diff — universal concepts across all VCS. Understanding these is essential before learning any specific tool.
05
SCM ≠ VCSSCM is the broader discipline (version control + build + release + change + environment management). DevOps automates SCM end-to-end.
06
Next: Lecture 14SVN, Mercurial, and Git — overview and examples. We'll see how each system works in practice with hands-on command examples.
🎯
Exam tip: Know the three VCS generations with examples (Local: RCS, Centralized: SVN, Distributed: Git). Be able to explain the SCCS → RCS → CVS → SVN → Git timeline with dates. Understand the difference between SCM and VCS. Know why Git won (speed, branching, integrity, GitHub, open source).